\chapter{Description g\'en\'erale}
\label{chap:desc.generale}
\minitoc


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Description du syst\`eme existant}
\label{sec:desc.generale.existant}

\subsection{JOnAS}
    Bull est leader du projet JOnAS au sein du consortium
OW2. Bull en ma\^itrise le coeur et g\`ere les contributions et la
roadmap. Il contribue aussi aux composants externes utilis\'es
dans JOnAS, comme Tomcat et Axis.
    JOnAS (Java Open Application Server) est un serveur
d'application certifi\'e Java EE 5 depuis mars 2009. Le projet
a d\'ebut\'e en 1998 et se place aujourd'hui en seconde position
des serveurs d'applications libres, derri\`ere JBoss.
    Dans sa version 5, JOnAS a la particularit\'e de s'appuyer sur le mod\`ele de composants 
OSGi, ce qui le rend adaptable dynamiquement et lui conf\`ere une grande
modularit\'e et une grande souplesse : par exemple, le chargement et le d\'echargement de
modules \`a chaud.

%-------------------------------------%

\subsection{JASMINe}
\label{subsec:desc.generale.existant.jasmine}
Pour r\'epondre aux besoins croissants de performance et de haute disponibilit\'e, les grappes de
serveurs d'application se d\'eveloppent dans les syst\`emes d'information des entreprises. Elles
soul\`event de nouveaux probl\`emes d'administration qui sont \`a la limite d'\^etre g\'erables par
l'humain de part leurs complexit\'es :
\begin{bulletList}
 \item le mod\`ele N-tiers, Java EE et les machines virtuelles JAVA, les multiples instances
       d'une grappe augmentent consid\'erablement le nombre d'entit\'es logicielles \`a
       administrer et le nombre d'\'ev\'enements \`a observer dans le syst\`eme global ;
 \item les nombreuses possibilit\'es de configuration et d'optimisation des performances
       offertes par ces intergiciels, coupl\'ees \`a la richesse des sp\'ecifications Java EE,
       n\'ecessitent le r\'eglage d'une multitude de param\`etres.
\end{bulletList}

L'outil d'administration JASMINe r\'epond \`a cette probl\'ematique en simplifiant la vie des
exploitants des plates-formes Java EE, compos\'ees par exemple des serveurs JOnAS, le serveur
d'application open source d'OW2. Le syst\`eme, dot\'e de fonctionnalit\'es \'evolu\'ees et de
comportements autonomes, vise \`a minimiser les co\^uts d'administration en :
\begin{bulletList}
 \item r\'eduisant les erreurs de configuration : une grande partie des mauvais
        fonctionnements observ\'es dans les environnements informatiques sont dus \`a des
        erreurs humaines de configuration des logiciels utilis\'es;
 \item am\'eliorant la r\'eactivit\'e en cas de dysfonctionnement : une intervention humaine
        pour d\'etecter une anomalie, r\'egler ou r\'eparer un service logiciel implique un d\'elai qui
        n'est pas toujours acceptable.
\end{bulletList}

\begin{figure}
   \includegraphics[width=1.0\textwidth]{Description/jasmine_monitoring}
   \caption{\label{fig:jasmine_monitoring} Architecture de JASMINe Monitoring}
\end{figure}

JASMINe est constitu\'ee de plusieurs modules assistant l'exploitant dans chacune de ses taches
d'administration :
\begin{bulletList}
\item Design/Deploy : outil de description d'architecture grappe Java EE et de d\'eploiement
        de la grappe sur l'architecture physique;
\item Monitoring : outil de d\'etection d'erreur permettant la remont\'ee d'alertes ou de
        notifications \`a l'exploitant; il sert aussi \`a suivre des performances en temps r\'eel ou hors
        ligne \`a partir de courbes graphiques;
\item Self-management : impl\'ementation de comportements autonomes pour r\'eparer ou
        optimiser une grappe.
\end{bulletList}
N\^otre travail s'int\`egrera au sein du module JASMINe Monitoring.

Pour d\'efinir les fonctions du nouveau module \`a r\'ealiser, il est necessaire de  comprendre la structure de JASMINe Monitoring.
JASMINe Monitoring est constitu\'e de plusieurs modules :

\begin{description}
    \item[Un bus de messages : l'Event-Switch] reposant sur \href{http://www.mulesource.org/display/MULE/Home}{Mule}, par lequel 
transitent toutes les communications.
    %\item[Un syst\`eme d'aggregation et filtrage : WildCat]
    \item[Des sondes avec MBeanCmd,] un utilitaire  en ligne de commande qui permet de d\'eployer des sondes sur 
des instances de serveurs et d'injecter les r\'esultats dans l'Event-Switch.
    \item[Un moteur de r\`egles: Drools,] qui est l'\'ex\'ecutant de la fonction d'auto-gestion. 
\href{http://www.jboss.org/drools}{Drools}, ou JBoss rules, est un BRMS (Business Rules Management System), qui permet de 
d\'eployer des r\`egles de management dans une organisation ou une application.
    \item[Une console web: JASMINe EoS] (Eye of SOA). Comme son nom l'indique, EoS permet par exemple de visualiser les sondes 
d\'eploy\'ees gr\^ace \`a ses diff\'erents modules (figure \ref{fig:eos}).
\end{description}

Les serveurs d'applications JOnAS offrent des MBeans pour \^etre surveill\'es.  MBeanCmd est un outil en ligne de commande,
\'ecrit en Java, pour interagir avec ces MBeans expos\'es par les serveurs J2EE. MBeanCmd peut envoyer des commandes aux MBeans,
peut recevoir les resultats de la commande (par exemple la charge du CPU m\'esur\'ee par un MBean de la JVM).
Ces resultats peuvent \^etre affich\'es, enregistr\'es dans un fichier ou peuvent servir pour construir des graphes.
Ils sont aussi envoy\'es vers l'Event-Switch de JASMINe (cf. figure \ref{fig:eos}).

Dans l'Event-Switch, ces r\'esultat sont dirig\'es vers differents points de sortie, soit pour \^etre persist\'es dans une base de 
donn\'ees, soit pour \^etre affich\'es comme graphe (dans les modules QuickVisu ou Monitoring de la console web JASMINe EoS).
Ces r\'esultats seront aussi utilis\'es comme entr\'es pour le moteur de r\`egles Drools qui executera des t\^aches sp\'ecifiques,
configur\'ees par l'administrateur.

\begin{figure}
   \includegraphics[width=1.0\textwidth]{Description/eos}
   \caption{\label{fig:eos} La console EoS, affichant un module de monitoring.}
\end{figure}

%-------------------------------------%

\subsection{Description du nouveau module}

Un type de t\^ache qui peut \^etre d\'efinie par l'administrateur est une notification.
Ces notifications seront d\'eclench\'ees par le moteur de r\`egles open source Drools et persist\'ees aussi en
base de donn\'ees. Un workflow humain permettra de g\'erer le cycle de vie de la notification et ses
interactions avec l'op\'erateur (visualisation en d\'etail, acquittement, etc.).

Des \'etapes pr\'eliminaires sont necessaires pour r\'ealiser ce nouveau module :
\begin{bulletList}
 \item L'extraction du coeur de JASMINe EoS
 \item La r\'ealisation d'un installeur pour JASMINe Monitoring
\end{bulletList}

Ces \'etapes seront detaill\'es dans la section \ref{chap:fonctionnalite}.




% Un peu de code :
% \begin{lstlisting}[language=Java]

% package org.ow2.jasmine.monitoring.installer;

% public class Main {
	
% public static void main(String[] args) {
        
%         new GenerateDP(args);
% 		//new GenerateDP();
%         /*for (String s : args)
%         	System.out.println("Arg "+s);*/
%         new GenerateES(args);
    	
%     }

% }

% \end{lstlisting}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Analyse de la concurrence pour le module de gestion de notifications}
\label{sec:desc.generale.concurrence}

\subsection{Oracle JRockit Mission Control (v3.0.3)}
\label{sec:desc.generale.concurrence.oracle}

Oracle JRockit Mission Control contient une suite d'outils pour monitoriser, g\'erer, profiler et \'eliminer les fuites de m\'emoire 
dans les
applications Java.
Plus pr\'ecis, ces outils sont :
\begin{itemize}
 \item une console interactive de gestion appel\'ee \textit{Management Console}, qui donne la possiblit\'e de visualiser le 
garbage collector
et d'autres statistiques de performance;
 \item un outil de performance \`a l'execution appell\'e \textit{Runtime Analyzer};
 \item un outil d'analyse de memoire  appell\'e \textit{Memory Leak Detector};
 \item un analyseur de latence qui montre d'une mani\`ere graphique les arr\^ets des files d'execution d\^us \`a la 
synchronisation, les entr\'ees et les sorties 
au niveau du syst\`eme des fichiers et du r\'eseau, l'allocation de memoire et les pauses du garbage collector.
\end{itemize}

Dans JRMC, une alerte est un message vers l'utilisateur qui l'avertit de l'occurence d'un \'ev\'enement.
Ces alertes peuvent \^etre d\'eclench\'ees quand la connection avec Oracle JRockit JVM a \'et\'e perdue ou quand un attribut
a atteint une certaine valeur ou limite, par exemple quand la m\'emoire utilis\'ee depasse 90\%.
On peut aussi \'etablir des contraintes pour limiter l'activation d'une r\`egle. Par exemple, on peut emp\^echer JRMC
d'envoyer des alertes la nuit ou entre certaines dates.

Pour ajouter une nouvelle r\`egle de d\'eclenchement pour une alerte, JRMC dispose d'un wizard qui permet de choisir 
l'attribut sur lequel on veut \'ecouter. Cet attribut est choisi avec l'aide d'une browser de MBeans (Fig. ~\ref{fig:mbean.browser}).
\begin{figure}[!htbp]
  \begin{center}
    \includegraphics[width=0.99\textwidth]{Description/Mbean_browser_tab}
  \end{center}
  \caption{MBean Browser}
  \label{fig:mbean.browser}
\end{figure}
Le pas suivant est d'\'etablir quelle est la limite pour le d\'eclenchement de l'alerte
et combien du temps (en secondes) les conditions de la r\`egle doivent \^etre vraies pour d\'eclencher l'alerte.
Ainsi, on a la possibilit\'e de pr\'eciser le temps (en secondes) entre deux d\'eclenchements cons\'ecutifs.
Une configuration nous permet d'\'etablir si le d\'eclenchement se passe sur un flanc ascendant (on d\'eclenche l'alerte 
quand la valeur de l'attribut monte) ou sur un flanc descendant (on d\'eclenche l'alerte 
quand la valeur de l'attribut descend).

Le wizard propose en suite des actions pour le d\'eclenchement d'une alerte. Ces actions sont:
\begin{itemize}
 \item envoyer une alerte vers l'application : afficher une notification dans la fen\^etre \textit{Trigger Alerts Dialog}. Dans cette fen\^etre 
on peut aussi voir les d\'etails de chaque alerte, sa date et heure, la r\`egle de d\'eclenchement, la source qui
l'a d\'eclench\'e et la valeur exacte de l'attribut \`a l'heure du d\'eclenchement;
 \item envoyer un avertissement dans la console (avec un System.out);
 \item envoyer un mail \`a une adresse sp\'ecifique (avec des options de CC et BCC);
 \item d\'emarrer un enregistrement JRockit Runtime Analyser (JRA) - pour cette option on doit pr\'eciser le type d'\'echantillonnage souhait\'e (ce qu'on 
veut \'echantillonner, par exemple le garbage collector, les m\'ethodes) et aussi la dur\'ee de l'enregistrement et le nom de fichier o\`u on veut d\'eposer 
les r\'esultats;
 \item cr\'eer une trace des files d'\'execution : \textit{thread stackdump}, pour trouver des informations sur l'activit\'ee des files d'\'execution 
d'une application. Ces informations peuvent \^etre utiles pour diagnostiquer l'application ou pour l'optimiser. Par exemple, les traces peuvent montrer
des interblocages entre les files d'ex\'ecutions. Pour activer cette option, on est cens\'e pr\'eciser la m\'ethode de sortie (soit un fichier de 
jurnalisation, soit une alerte syst\`eme). Les traces ont lieu d'habitude dans le cas d'une erreur.
\end{itemize}
\begin{figure}[!htbp]
  \begin{center}
    \includegraphics[width=0.99\textwidth]{Description/trigger_tab}
  \end{center}
  \caption{Fen\^etre Trigger - permet la d\'efinition et l'\'edition des notifications}
  \label{fig:trigger.tab}
\end{figure}

La d\`erniere \'etape est optionnelle. On peut limiter le d\'eclenchement d'une action; par exemple on veut que l'action se d\'eclenche tous les
deux jours de la semaine, dans un interval de jours pr\'ecis ou entre des heures sp\'ecifiques. 
Dans la Figure ~\ref{fig:trigger.tab} on peut observer la fen\^etre principale pour definir et \'editer les notifications.


%-------------------------------------%

\subsection{JBoss Operations Network (v2.1)}
\label{sec:desc.generale.concurrence.jboss}

JBoss ON est compos\'e d'une console capable de monitorer des plate-formes, des serveurs et des services. Elle consiste d'un serveur et d'un 
agent. 
Le serveur administre, configure et contr\^ole toutes les resources.
Il g\'ere les \'ev\'enements qui surviennent, en g\'en\'erant des alertes et/ou d\'eclenchant des operations qui correspondent \`a ces 
\'ev\'enements.
La partie Monitoring de JBoss ON correspond dans notre syst\`eme \`a JASMINe Monitoring. 
La partie que nous int\'eresse le plus est la partie de gestion de notifications ou \textit{alertes} dans JBoss ON.
Le m\'ecanisme d'alertes offre des notifications pour des conditions d\'efinies par l'utilisateur. Ce m\'ecanisme est utilis\'e pour notifier 
les administrateurs en cas de probl\`emes de performance ou d'\'echec d'op\'eration.

Ces alertes peuvent \^etre d\'efinies \`a partir de chaque ressource (plate-forme, serveur ou service), en prenant en consid\'eration des
param\`etres sp\'ecifiques. Par exemple, pour le syst\`eme de fichiers d'une platforme, les param\`etres qu'on peut prendre en compte sont : Free
Space, Used Percentage, Disk Reads, Disk Reads per Minute, Disk Writes, Disk Writes per Minute, Disk Read Bytes, Disk Read Bytes per Minute,
Disk Write Bytes, Disk Write Bytes per Minute, Disk Queue, etc.
Les types de ressources que peuvent \^etre g\'er\'ees sont : 
\begin{itemize}
 \item plate-formes Java, Linux, Windows;
 \item serveurs Apache, JBoss, JMX, Postgres, Tomcat, IIS;
 \item services Files System, Network Adapter, CPU.
\end{itemize}
En prenant l'exemple d'une plate-forme pour laquelle on surveille la carte r\'eseau, on peut d\'efinir une alerte et la nommer.
Ensuite, on va \'etablir l'ensemble de conditions dans lesquelles elle se d\'eclenche. La notification peut se d\'eclencher 
quand n'importe quelle 
condition de l'ensemble est vraie (option ANY) ou quand toutes les conditions de l'ensemble sont vraies (option ALL).

Quand on d\'efinit une condition, la premiere \'etape est de d\'efinir la \textit{If condition} de l'alerte. Elle peut \^etre de type 
\textit{Metric} 
(par exemple, l'espace libre d'un disque dur devient plus petit que 50\% de sa capacit\'e). A noter que ce type de condition est le 
plus riche. D'autres types de conditions sont \textit{Trait} et 
\textit{Availability}. Alors que les mesures sont des donn\'ees num\'eriques et ont la tendance de se changer fr\'equemment, les \textit{traits} sont 
plut\^ot statiques et peuvent \^etre compar\'es avec la derni\`ere valeurs m\'esur\'ee pour ce \textit{trait}. Par exemple, pour une plate-forme, on peut 
comparer la version actuelle de l'OS avec la derni\`ere valeur mesur\'ee. En ce qui concerne la disponibilit\'e d'une 
ressource, l'administrateur est notifi\'e si la ressource change son \'etat, de disponible \`a indisponible ou 
vice-versa.

Une option int\'eressante est l'\textit{Alert Dampening} ou l'att\'enuation des alertes. \textit{Alert Dampening} est une forme d'agr\'egation 
de plusieurs alertes. Au lieu d'\^etre alert\'e chaque fois que l'ensemble de condition est evalu\'e comme vrai, l'administrateur peut demander, par 
exemple, d'\^etre alert\'e une fois chaque X fois que l'ensemble de conditions est vrai.

Une autre option est l'\textit{Action Filtering}. On peut, apr\`es avoir d\'eclench\'e l'alerte, la d\'esactiver, pour ne pas d\'eclencher d'autres 
alertes du m\^eme type jusqu'au moment que le probl\`eme soit resolu. 

La derni\`ere partie de la d\'efinition d'une alerte est la \textit{Notification}. L'administrateur doit \^etre averti d'une mani\`ere ou de 
l'autre quand l'ensemble de conditions est vrai. En JBoss ON, les notifications sont envoy\'ee par mail ou par SNMP trap.
L'envoi de mail peut se faire par r\^ole. On peut d\'efinir des r\^oles \`a notifier. Chaque utilisateur a un r\^ole attribu\'e. Le compte utilisateur correspond
\`a une adresse mail o\`u l'alerte est envoy\'ee.
L'alerte peut \^etre aussi envoy\'ee par compte utilisateur, sans passer par r\^ole, ou directement en sp\'ecifiant une adresse mail, sans qu'elle soit 
associ\'ee \`a un r\^ole ou \`a un nom d'utilisateur.

La journalisation des conditions est indispensable pour une application de telle sorte. Elle est responsable avec l'enregistrement du moment quand une condition 
d'alerte \`a \'et\'e remplie ainsi que la valeur exacte du param\`etre qui a declench\'e l'alerte.

L'alerte peut \^etre activ\'ee ou desactiv\'ee. Quand elle est active, ses conditions de d\'eclenchement sont verifi\'ees par le moteur qui traite les alertes. 
Si une alerte est inactive, elle n'est pas trait\'ee par le moteur et ses conditions ne sont pas verifi\'ees.

Le m\^eme type d'alerte peut \^etre d\'efinie pour un \'ev\'enement. Les \'ev\'enements sont sp\'ecifiques aux plate-formes :
\begin{itemize}
 \item Windows (Windows events);
 \item Apache Server (les fichiers de journalisation);
 \item JBossAS Server (les fichiers de journalisation).
\end{itemize}

La source d'un \'ev\'enement est attach\'ee \`a une ressource particulliere et elle d\'efinit l'origine d'un \'ev\'enement. Une source typique d'\'ev\'enements est
le fichier de log d'une ressource. Pour le futur, JBoss ON envisage comme source pour les \'ev\'enements, aussi des notifications JMX. 
Un \'ev\'enement est declench\'e chaque fois que les conditions d'une source sont remplies. L'\'ev\'enement signale les valeurs qui correspondent au 
crit\`ere 
\'etabli. Par exemple, quand une entr\'ee du fichier de jurnalisation correspond \`a des contraintes de gravit\'e est aux expressions r\'eguli\`eres d\'efinies, 
l'\'ev\'enement est signal\'e.
Chaque \'ev\'enement a donc des niveaux de gravit\'e associ\'ee (\textit{severity}). Ces niveaux sont: \textit{Debug}, \textit{Info}, \textit{Warn}, 
\textit{Error}, \textit{Fatal}. Dans la Figure ~\ref{fig:events.in.jbosson} on peut observer une suite d'\'ev\'enements, avec leurs sources, leurs 
types 
de gravit\'e, le moment de d\'eclenchement. On peut aussi acquiter les \'ev\'enements signal\'es.
L'option qui nous concerne dans la d\'efinition d'un \'ev\'enement est la d\'efinition d'une alerte qui peut se d\'eclencher \`a la suite d'un 
\'ev\'enement.
Les conditions de l'alerte sont les m\^emes que les conditions \'enum\'er\'ees ci-dessus, mais, en plus, on peut choisir au lieu de \textit{Metric}, 
\textit{Trait} ou \textit{Availability}, l'option \textit{Severity}, pour d\'eclencher l'alerte pour des \'ev\'enements avec une telle gravit\'e.


\begin{figure}[!htbp]
  \begin{center}
    \includegraphics[width=0.99\textwidth]{Description/events_in_jbosson}
  \end{center}
  \caption{Ev\'enements en JBoss ON}
  \label{fig:events.in.jbosson}
\end{figure}

%-------------------------------------%

\subsection{Comparaison entre les deux solutions \'etudi\'ees}
\label{sec:desc.generale.concurrence.comparaison}
Pour conclure, le MBeans Browser de JRMC offre une bonne vision sur tous les attributs qu'on peut surveiller.
Dans notre application, on utilisera aussi une m\'ethode similaire pour pouvoir naviguer parmi les attributs \`a
monitorer. Les attributs seront class\'es par
"th\'eme" (des attributs de la JVM, des attributs physiques, de genre chargement du processeur, etc).
Un probl\`eme observ\'e dans les deux consoles est la manque de l'unit\'e de mesure qui s'applique
pour certains attributs. Par exemple, quand on met une limite sur l'espace libre du disque dur d'un serveur,
on ne sait pas exactement s'il faut la mettre dans Mo ou dans Go.
L'application qu'on souhaite mettre en   \oe uvre indiquera des unit\'es de mesure qui se changeront selon
l'attribut s\'electionn\'e.

Dans JRMC, l'assistant pour cr\'eer une nouvelle r\`egle est facile \`a utiliser et l'\'edition d'une r\`egle se 
fait dans la fen\^etre principale des Triggers.
Par contre, on ne peut pas ajouter plusieurs attributs, chacun avec sa propre limite pour cr\'eer une seule r\`egle, 
comme dans JBoss ON. M\^eme si, dans JBoss ON cette fonction est assez limit\'ee (on peut choisir le d\'eclenchement d'une alerte soit quand
une des r\`egles est vraie - ANY, soit quand toutes sont vraies - ALL), elle n'existe pas dans JRMC.

Dans notre produit, on souhaiterait pouvoir cr\'eer facilement des r\`egles bas\'ees sur des expressions logiques, avec divers 
op\'erateurs. 
Exemple : 
\begin{verbatim}
 when Condition_1 AND (Condition_2 OR Condition_3) then Trigger_Alert
\end{verbatim}
o\`u
\begin{verbatim}
 Condition_1 : attribute_1 == 0
 Condition_2 : attribute_2 matches ``expression``
 Condition_3 : attribute_3 < limit
\end{verbatim}

L'ensemble de conditions peut \^etre trouv\'e vrai un grand nombre de fois dans un intervalle de temps. 
Une option int\'eressante peut \^etre de d\'eclencher la notification si dans un intervalle de temps precis\'e par
l'utilisateur, l'ensemble de conditions est jug\'e comme vrai plusieurs fois. 
Donc par exemple, si dans les 5 dernier\`es minutes, l'ensemble de conditions est valid\'e 10 fois,
l'utilisateur peut decider d'envoyer une seule notification, et pas 10 notifications diff\'erentes.
On voit cette fonctionalit\'e comme option pour le d\'eclenchement d'une notification.
Cette solution est implement\'ee dans JBoss ON.

Une autre option qui pourrait \^etre utile est de pr\'eciser pour chaque condition, 
un intervalle de temps dans lequelle elle est \'evalu\'ee comme vraie 
pour \^etre consider\'ee vraie dans l'ensemble de conditions.
Par exemple, pour un pic de CPU jusqu'\`a 100\%, si le pourcentage reste le m\^eme 
pour 5 minutes, {\c c}a peut devenir la source d'une notification mais si le taux d'utilisation du processeur
revient dans les limites \'etablies apr\`es 10 secondes, l'administrateur peut consid\'erer ce comportement comme
normal.

On peut donner \`a l'administrateur la possibilit\'e de pouvoir d\'esactiver la notification juste apr\`es le
moment du d\'eclenchement. Ce comportement est aussi implement\'e dans JBoss ON.

En ce qui concerne le type de notification \`a envoyer, JBoss ON offre des posibilit\'es assez limit\'es (on ne peut
envoyer que des mails). Par contre, l'envoi de mail peut se faire par r\^ole. Dans le syst\`eme 
d\'ej\`a existant, la gestion des r\^oles n'est pas implement\'ee.
Par contre, on proposera une diversit\'e de types de notifications \`a envoyer (fen\^etre de type pop-up,
mail, insertion dans un fichier de jurnalisation). Cela va \^etre r\'ealis\'e par la g\'en\'ericit\'e de l'objet Notification
qui va pouvoir utiliser plusieurs protocoles.

Enfin, le syst\`eme de jurnalisation de l'application peut \^etre complet\'e par une base de donn\'ees o\`u
les notifications vont \^etre stock\'ees et sur laquelle on peut effectuer des requ\^etes par date,
par degr\'e de gravit\'e de la notification, etc.

L'administrateur doit pouvoir acquiter les notifications et regarder en d\'etail ces notifications.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Principaux probl\`emes rencontr\'es}
\label{sec:desc.generale.problemes}
\subsection{L'interface graphique}
\label{sec:desc.generale.interf}

Comme JASMINe Monitoring est un outil destin\'e au milieu industriel, pour l'administration des infrastructures fortement clusteris\'ees,
le niveau technique des administrateurs est \'elev\'e. Ces utilisateurs ont l'habitude de faire toutes les \'etapes - maintenance,
diagnostique, r\'eparation - de fa\c{c}on ''manuelle``. Notre outil doit trouver un \'equilibre entre une interface graphique guid\'ee, qui
minimise la possibilit\'e d'erreur humaine
et le contr\^ole que ces utilisateurs souhaitent. Si cet equilibre n'est pas r\'ealis\'e, l'outil risque d'\^etre rejet\'e par les
utilisateurs-cible.
%-------------------------------------%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%end chapter2.tex